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DETAILED ACTION 



Claim Objections 



1 . Claims objected to because of the following informalities: 

■ Claim 5 should be dependent on claim 4 because claim 5 currently depends from 
claim 2 and call for "said datum", however, "said datum" lacks antecedent basis 
as claims 2 or 1 do not introduce "datum". Claim 4 provides antecedent basis for 
"datum", accordingly, claim 5 should depend from claim 4. This will be assumed 
for examination purposes. 

■ Similarly, claim 25 should be dependent on claim 24 because there is no 
antecedent basis for "said datum" in claim 23, claim 24 provide antecedent basis 
for this limitation. Claim 25 will be assumed to be dependent on claim 24 for the 
examination purposes. 

Appropriate correction is required. 



Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed 
publication in this or a foreign country, before the invention thereof by the applicant for a patent. 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
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granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

Claims 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 12.13. 14. 15. 16. 17. 18. 19. 20. 21. 23. 24. 
25. 26, 27. 29. 30 are rejected under 35 U.S.C. 102(b) as being anticipated by 
Auerbach et al. (US 5.673,316). hereinafter Auerbach. 

t 

Regarding Claim 1, Auerbach discloses a method of generating a manifest that 
governs the execution of a software object (Column 1, lines 39-41, "This invention 
describes a method for the creation, distribution, and sale of digital information 
using the methods and techniques of secure cryptographic envelopes"), the 

* 

method comprising: 

receiving a specification indicative of requirements for the execution of the 
software object, the specification referring to one or more components (Column 5, lines 
55-62, "Assemble information parts to be included in the cryptographic 
envelope", also at Column 4, lines 9-18, since the envelope contains both 
encrypted and unencrypted parts, during cryptographic envelope creation, 
system must know which part needs to be encrypted, as a result it is implied that 
this information needs to be delivered to the envelope creator and can be 
interpreted as a specification indicative of requirements for the execution of the 
software object, also the part keys included in envelope can be interpreted as 
specification indicative of requirements for the execution of the software object ); 

Note: Auerbach discloses that contents of the envelope are not restricted to 
movies of music and discloses at Column 4, lines 4-8 that "[D]document parts are the 



Application/Control Number: 10/658,149 Page 4 

Art Unit: 2135 

"contents". Some examples of document parts are abstracts, table of contents, figures, 
tables, and texts, They Could also be portions of an executable program, a library of 
sub-routines, software modules, or object components". 

generating a manifest based on said specification, including accessing said one 

« 

or more components (Column 6, lines 15-27, "Create a list 209 of information parts, 
listing all the parts assembled and computing a secure hash of each of the parts 
listed"), said manifest comprising one or more rules governing what may be loaded into 
an address space of the software object (Column 6, lines 15-27, "terms and 
conditions" and also a list of keys for all encrypted parts as disclosed at Column 
6, lines 1-5). 

Regarding Claim 2, the rejection of claim 1 is incorporated and Auerbach further 
discloses wherein said specification identifies one or more modules (As established 
above in the rejection of claim 1, since the envelope contains both encrypted and 
unencrypted parts, during cryptographic envelope creation, system must know 
which part needs to be encrypted, as a result it is implied that this information 
needs to be delivered to the envelope creator and can be interpreted as a 
specification identifying one of more modules) , and wherein generating the 

■ 

manifest comprises including, in said manifest, the identities of the one or more 
modules identified in the specification (Column 5, 19-26, "We apply a secure hash 
function, MessageDigest5 (MD5) (see. e.g., [1] for details), to each part included in 
a cryptographic envelope and create a list. Referring to Fig. 3, each entry in the 
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list contains the part name or reference 302 and a secure hash 301 of the 
information part corresponding to the part name") 

Regarding Claim 3, the rejection of claim 2 is incorporated and Auerbach further 
discloses wherein said specification indicates that a first one of said one or more 
modules may be loaded into the address space of the software object (Column 6, lines 
12-14, "Include in the cryptographic envelope clear text parts such as "teasers", 
abstract, and a table of content 201." also at Fig. 3, Numerals 302 and 301, 
Abstract is listed under list of parts) and wherein generating the manifest comprises 
including the identity of said first one of said one or more modules on list of acceptable 
modules (Fig. 3, Numerals 302 and 301) 

Regarding Claim 4, the rejection of claim 2 is incorporated and Auerbach further 
discloses wherein said specification indicates that a first one of said one or more 
modules may not be loaded into the address space of the software object (Column 5, 
lines 63-67, as established above in the rejection of claim 1, since the envelope 
contains both encrypted and unencrypted parts, during cryptographic envelope 
creation, system must know which part needs to be encrypted, as a result it is 
implied that this information needs to be delivered to the envelope creator and 
can be interpreted as a specification identifying one of more modules may not be 
loaded into the address space of the software object [encrypted parts]), and 
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wherein generating the manifest comprises including in the manifest a datum that 
identifies said first one of said one or more modules (Fig. 3, "Encrypted Doc Part 1") 

Regarding Claim 5, the rejection of claim 4 is incorporated and Auerbach further 
discloses wherein said datum comprises a hash of said first one of said one or more 
modules (Fig. 3, MD5 of "Encrypted doc part 1", which is 24FDEC234...") 

Regarding Claim 6, the rejection of claim 2 is incorporated and Auerbach further 
discloses wherein said specification indicates whether said manifest will contain hashes 
of said one or more modules (Fig. 3, "MD5 of Part"). 

■ 

Regarding Claim 7, the rejection of claim 1 is incorporated and Auerbach further 
discloses wherein said one or more components comprise a key (Column 2, lines 20- 
22, "With this invention, each of the information parts is encrypted with a 
corresponding part encryption key to generate an encrypted information part" 
and at Column 2, lines 26-28, "The envelope, then, includes the encrypted 
information parts, the unencrypted information parts, the encrypted part 
encryption keys and list of parts"), 

wherein said specification indicates either that modules signed with said key may 
be loaded into said address space or that modules signed with said key may not be 
loaded into said address space (Column 2, lines 28-36, "Finally, the list of parts is 
signed with a secret key to produce a signature, and this signature is also 
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included in the envelope. The integrity of the list can be checked using a second 
public key associated with the secret key that was used to sign the list. The 
integrity of any one information part can be checked by computing a second hash 
on the part and comparing the second hash with the corresponding hash for the 
part in the list."), and 

wherein generating said manifest comprises: retrieving said key from a file 
identified in said specification; and including said key in said manifest (Column 2, lines 
26-28, "The envelope, then, includes the encrypted information parts, the 
unencrypted information parts, the encrypted part encryption keys and the list of 
parts"). 

Regarding Claim 8, the rejection of claim 1 is incorporated and Auerbach further 
discloses wherein said one or more components comprise a module (Column 4, lines 
4-8, "Documents parts are abstracts, table of contents, figures, tables, and texts, 
They could also be portions of an executable program, a library of subroutines, 
software modules, or object components"), wherein said specification indicates that 
said module may not be loaded into said address space (Column 5, lines 63-67, as 
established above in the rejection of claim 1, since the envelope contains both 
encrypted and unencrypted parts, during cryptographic envelope creation, 
system must know which part needs to be encrypted, as a result it is implied that 
this information needs to be delivered to the envelope creator and can be 
interpreted as a specification identifying one of more modules may not be loaded 
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into the address space of the software object [encrypted parts]), and wherein 
generating said manifest comprises: computing a hash of said module (Column 5, lines 
19-21, "We apply a secure hash function, MessageDigest5 (MD5) (see, e.g., [1] for 
details), to each part included in a cryptographic envelope and create a list."); and 
including said hash in said manifest (Fig. 3, Numeral 209, "MD5 of Part" is included 
in the BOM section of cryptographic envelope). 

Regarding claim 9, the rejection of claim 1 is incorporated and Auerbach further 
discloses wherein said generating act comprises: based on said specification, creating a 
data structure representative of said specification; and generating said manifest based 
on said data structure (Fig. 3, "BOM", and at Column 5, lines 13-34) 

Regarding Claim 10, the rejection of claim 1 is incorporated and Auerbach 
further discloses wherein receiving a key associated with a vendor or distributor of said 
software object (Column 5, lines 27-28, "The list is then digitally signed with a 
secret key known only to the DS (Document Server)"); 

signing said manifest with said to produce a digital signature (Column 5, lines 
27-28, "The list is then digitally signed with a secret key known only to the DS 
(Document Server)"); and 

including said digital signature in said manifest (Fig. 2, Numeral 208, "Signature 
on list of parts") and at Column 2, lines 28-30, "Finally, the list of parts is signed 
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with a secret key to produce a signature, and this signature is also included in the 
envelope."). 

Regarding Claim 12, Auerbach discloses computer implemented method of 
generating a manifest, the method comprising: 

parsing a specification of requirements to be included in the manifest, the 
requirements defining a policy that governs what can be loaded into an address space 
of a software object associated with the manifest (Column 5, lines 55-62, "Assemble 
information parts to be included in the cryptographic envelope", also at Column 
4, lines 9-18, since the envelope contains both encrypted and unencrypted parts, 
during cryptographic envelope creation, system must know which part needs to 
be encrypted, as a result it is implied that this information needs to be delivered 
to the envelope creator and can be interpreted as a specification indicative of 
requirements for the execution of the software object, also the part keys included 
in envelope can be interpreted as specification indicative of requirements for the 
execution of the software object ); 

accessing one or more components that are identified by the specification and 
that are external to the specification (Column 5, lines 63-67, "1-c - Generate random 
PEKs (part encryption keys) 202, one for each part to be encrypted. 1-d - Encrypt 
document parts with their respective PEKs to form the encrypted parts (203, 204, 
205), which are included in the cryptographic envelope"); and 



i 
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generating a manifest based on at least one of the accessed objects (Column 6, 
lines 15-27, "terms and conditions" and also a list of keys for all encrypted parts 
as disclosed at Column 6, lines 1-5). 

Regarding Claim 13, the rejection of claim 12 is incorporated and Auerbach 
further discloses wherein said one or more components comprise an executable module 
(Column 4, lines 4-8, "Documents parts are abstracts, table of contents, figures, 
tables, and texts, They could also be portions of an executable program, a library 
of subroutines, software modules, or object components"), and 

wherein generating said manifest comprises: 

including in said manifest an identification of said executable module and an 
indication that either: said executable module may be loaded into said address space; 
or said executable module may not be loaded into said address space (Fig. 3, "list of 
parts" that list abstract which can be loaded into address space because it is not 
encrypted and Encrypted Doc Part 1 which cannot be loaded into address space 
because it is encrypted). 

Regarding Claim 14, the rejection of claim 14 is incorporated and Auerbach 
further discloses wherein said identification of said executable module comprises a 
hash of said executable module (Fig. 3, Numeral 209, "MD5 of part") 
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Regarding Claim 15, the rejection of claim 13 is incorporated and Auerbach 
further discloses wherein said one or more components comprise a key (Column 2, 
lines 20-22, "With this invention, each of the information parts is encrypted with a 
corresponding part encryption key to generate an encrypted information part" 
and at Column 2, lines 26-28, "The envelope, then, includes the encrypted 
information parts, the unencrypted information parts, the encrypted part 
encryption keys and list of parts"), wherein said specification indicates either that 
modules signed with said key may be loaded into said address space or that modules 
signed with said key may not be loaded into said address space (Column 2, lines 28- 
36, "Finally, the list of parts is signed with a secret key to produce a signature, 
and this signature is also included in the envelope. The integrity of the list can be 
checked using a second public key associated with the secret key that was used 
to sign the list. The integrity of any one information part can be checked by 
computing a second hash on the part and comparing the second hash with the 
corresponding hash for the part in the list"), and wherein generating said manifest 
comprises: 

retrieving said key from a file identified in said specification (Column 5, lines 27- 
28, "The list is then digitally signed with a secret key known only to the DS 
(Document Server)"); and 

including said key in said manifest (Column 6, lines 15-27, "terms and 

conditions" and also a list of keys for all encrypted parts as disclosed at Column 
6, lines 1-5). 
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Regarding Claim 16, the rejection of claim 12 is incorporated and Auerbach 
further discloses receiving a key associated with a vendor or distributor of said software 
object (Column 5, lines 27-28, "The list is then digitally signed with a secret key 
known only to the DS (Document Server)"); signing said manifest with said to 
produce a digital signature (Column 5, lines 27-28, "The list is then digitally signed 

■ 

with a secret key known only to the DS (Document Server)"); and including said 
digital signature in said manifest (Fig. 2, Numeral 208, "Signature on list of parts") 
and at Column 2, lines 28-30, "Finally, the list of parts is signed with a secret key 
to produce a signature, and this signature is also included in the envelope."). 

Regarding Claim 17, Auerbach discloses a method of specifying constraints on 
the use of software (Column 1, lines 39-41, "This invention describes a method for 
the creation, distribution, and sale of digital information using the methods and 
techniques of secure cryptographic envelopes") comprising: 

creating a specification concerning what may be loaded into an address space of 
the software, the specification referring to one or more components that are external to 
the software and external to the specification (Column 5, lines 55-62, "Assemble 
information parts to be included in the cryptographic envelope", also at Column 
4, lines 9-18, since the envelope contains both encrypted and unencrypted parts, 
during cryptographic envelope creation, system must know which part needs to 
be encrypted, as a result it is implied that this information needs to be delivered 



Application/Control Number: 10/658,149 Page 13 

Art Unit: 2135 

to the envelope creator and can be interpreted as a specification indicative of 
requirements for the execution of the software object, also the part keys included 
in envelope can be interpreted as specification indicative of requirements for the 
execution of the software object ); 

using a manifest generation tool to generate a manifest based on the 
specification (Column 6, lines 15-27, "terms and conditions" and also a list of keys 
for all encrypted parts as disclosed at Column 6, lines 1-5), wherein the manifest 
generation tool does at least one of: 

including, in said manifest, data from one of said one or more components 
(Fig. 2, Numerals 201, 203, 204); or 

computing a value based on one of said one or more components and 
including the computed value in said manifest (Fig. 3, Numeral 209, "MD5 of 
part"); and 

distributing the generated manifest with the software (Fig. 2, Numeral 206, 
"terms and Conditions" and Numeral 207, "BOM"), wherein the manifest comprises 
rules describing what may be loaded into the address space of the software (Column 6, 
lines 15-27, "terms and conditions" and also a list of keys for all encrypted parts 
as disclosed at Column 6, lines 1-5). 

Regarding Claim 18, the rejection of claim 17 is incorporated and Auerbach 
further discloses wherein said one or more components comprises a module, wherein 
said specification indicates either that said module may be loaded into said address 



! 
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space or that said module may not be loaded into said address space (Column 5, lines 

■ 

63-67, as established above in the rejection of claim 1, since the envelope 
contains both encrypted and unencrypted parts, during cryptographic envelope 
creation, system must know which part needs to be encrypted, as a result it is 
implied that this information needs to be delivered to the envelope creator and 
can be interpreted as a specification identifying one of more modules may or may 
not be loaded into the address space of the software object, based on whether 
the part is encrypted or not]), and wherein said manifest generation tool does at least 
one of: including an identifier of said module in said manifest; or computing a hash of 
said module and including the hash in said manifest (Column 5, 19-26, "We apply a 
secure hash function, MessageDigestS (MD5) (see. e.g., [1] for details), to each 
part included in a cryptographic envelope and create a list. Referring to Fig. 3, 
each entry in the list contains the part name or reference 302 and a secure hash 
301 of the information part corresponding to the part name"). 

Regarding Claim 19, the rejection of claim 17 is incorporated and Auerbach 
further discloses wherein said one or more components comprise a key (Column 2, 
lines 20-22, "With this invention, each of the information parts is encrypted with a 
corresponding part encryption key to generate an encrypted information part" 
and at Column 2, lines 26-28, "The envelope, then, includes the encrypted 
information parts, the unencrypted information parts, the encrypted part 
encryption keys and list of parts"), wherein said specification indicates either that 
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modules signed with said key may be loaded into said address space or that modules 
signed with said key may not be loaded into said address space (Column 2, lines 28- 
36, "Finally, the list of parts is signed with a secret key to produce a signature, 
and this signature is also included in the envelope. The integrity of the list can be 
checked using a second public key associated with the secret key that was used 
to sign the list. The integrity of any one information part can be checked by 
computing a second hash on the part and comparing the second hash with the 
corresponding hash for the part in the list"), and wherein said manifest generation 
tool retrieves said key from a file identified in said specification, and includes a 
certificate for said key in said manifest (Column 2, lines 26-28, "The envelope, then, 
includes the encrypted information parts, the unencrypted information parts, the 
encrypted part encryption keys and the list of parts"). 

( 

■ 

« 

Regarding Claim 20, the rejection of claim 17 is incorporated and Auerbach 
further discloses said manifest generation tool creates an intermediate data structure 
representative of said specification, and generates said manifest based on said 
intermediate data structure (Fig. 3, "BOM", and at Column 5, lines 13-34). 

Regarding Claim 21, the rejection of claim 17 is incorporated and Auerbach 
further discloses receiving a key associated with a vendor or distributor of said software 
object (Column 5, lines 27-28, "The list is then digitally signed with a secret key 
known only to the DS (Document Server)"); 
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signing said manifest with said to produce a digital signature (Column 5, lines 
27-28, "The list is then digitally signed with a secret key known only to the DS 
(Document Server)"); and 

including said digital signature in said manifest (Fig. 2, Numeral 208, "Signature 
on list of parts") and at Column 2, lines 28-30, "Finally, the list of parts is signed 
with a secret key to produce a signature, and this signature is also included in the 
envelope."). 

Regarding Claim 23, Auerbach discloses a system for generating a manifest 
(Fig. 1) comprising: 

a first parser that receives a manifest specification indicative of requirements for 
a manifest, the first parser generating a representation of said requirements, said 
requirements relating to what may be loaded into an address space of a software 
object, said specification referring to one or more components external to said software 
and external to said specification (Column 5, lines 55-62, "Assemble information 
parts to be included in the cryptographic envelope", also at Column 4, lines 9-18, 
since the envelope contains both encrypted and unencrypted parts, during 
cryptographic envelope creation, system must know which part needs to be 
encrypted, as a result it is implied that this information needs to be delivered to 
the envelope creator and can be interpreted as a specification indicative of 
requirements for the execution of the software object, also the part keys included 
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in envelope can be interpreted as specification indicative of requirements for the 
execution of the software object ); 

a first manifest generator that generates a manifest based on said representation 
and includes in said manifest information contained in, or computed based on, said one 
or more components (Column 6, lines 15-27, "terms and conditions" and also a list 
of keys for all encrypted parts as disclosed at Column 6, lines 1-5). 

Regarding Claim 24, the rejection of claim 23 is incorporated and Auerbach 
further discloses said one or more components comprise a module (Column 4, lines 4- 
8, "Documents parts are abstracts, table of contents, figures, tables, and texts, 
They could also be portions of an executable program, a library of subroutines, 
software modules, or object components"), and wherein said first manifest generator 
generates said manifest by including, in said manifest, a datum that identifies said 
module (Fig. 3, "list of parts" that list abstract which can be loaded into address 
space because it is not encrypted and Encrypted Doc Part 1 which cannot be 
loaded into address space because it is encrypted). 

Regarding Claim 25, the rejection of claim 24 is incorporated and Auerbach 
further discloses wherein said datum comprises a hash of said module (Fig. 3, Numeral 
209, "MD5 of Part") 
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Regarding Claim 26, the rejection of claim 23 is incorporated and Auerbach 
further discloses wherein said one or more components comprise a key (Column 2, 
lines 20-22, "With this invention, each of the information parts is encrypted with a 
corresponding part encryption key to generate an encrypted information part" 
and at Column 2, lines 26-28, "The envelope, then, includes the encrypted 
information parts, the unencrypted information parts, the encrypted part 
encryption keys and list of parts"), wherein said specification indicates either that 
modules signed with said key may be loaded into said address space or that modules 
signed with said key may not be loaded into said address space (Column 2, lines 28- 
36, "Finally, the list of parts is signed with a secret key to produce a signature, 
and this signature is also included in the envelope. The integrity of the list can be 
checked using a second public key associated with the secret key that was used 
to sign the list. The integrity of any one information part can be checked by 
computing a second hash on the part and comparing the second hash with the 
corresponding hash for the part in the list"), and wherein generating said manifest 
comprises: 

retrieving said key from a file identified in said specification (Column 5, lines 27- 
28, "The list is then digitally signed with a secret key known only to the DS 
(Document Server)"); and 

including said key in said manifest (Column 6, lines 15-27, "terms and 
conditions" and also a list of keys for all encrypted parts as disclosed at Column 
6, lines 1-5). 



I 
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Regarding Claim 27, the rejection of claim 23 is incorporated and Auerbach 
further discloses receiving a key associated with a vendor or distributor of said software 
object (Column 5, lines 27-28, "The list is then digitally signed with a secret key 
known only to the DS (Document Server)"); signing said manifest with said to 
produce a digital signature (Column 5, lines 27-28, "The list is then digitally signed 
with a secret key known only to the DS (Document Server)"); and including said 
digital signature in said manifest (Fig. 2, Numeral 208, "Signature on list of parts") 
and at Column 2, lines 28-30, "Finally, the list of parts is signed with a secret key 
to produce a signature, and this signature is also included in the envelope."). 

Regarding Claim 29, the rejection of claim 23 is incorporated and Auerbach 
further discloses a second parser that receives a manifest specification indicative of 
requirements for a manifest (Column 9, lines 14-47, "Step 4: Buy Server 
Response"), the second parser generating a representation of said requirements in the 
same format as said first parser (Column 10, lines 9-34, "BSR"), wherein said first 
parser parses specifications in a first format and second parser parses specifications in 
a second format different from said first format (Column 10, lines 27-31), and wherein 
first manifest generator generates said manifest based on a representation produced 
either by said first parser or said second parser (Column 10, lines 32-34, "Include 
transformed terms and conditions and other restrictions on the use of the 
documents in BSR 605. 4-h - Send BSR to user"). 
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Regarding Claim 30, the rejection of claim 23 is incorporated and Auerbach 
further discloses a second manifest generator that generates a manifest based on said 
representation, wherein said first manifest generator generates a manifest in a first 
format and second manifest generator generates a manifest in a second format different 
from said first format (Column 3, lines 45-53, "The creation event is usually done 
off-line by the content provider because of anticipated needs for a collection of 
digital documents to be super distributed. Alternatively, it could be triggered by a 
user request. In this case the cryptographic envelope would be created 
specifically for the user, and the cryptographic envelope may contain certain 
information specific to the user or the request"). 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 11, 22 and 28 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Auerbach in view of Wa tan a be et al. (US 2002/0108041 A1), hereinafter 
Watanabe. 

Regarding Claims 11, 22 and 28, the rejections of claims 1, 17 and 27 are 
incorporated and Auerbach discloses signing a manifest using the private key of the 
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vendor or distributor (Column 5, lines 27-28, "The list is then digitally signed with a 
secret key known only to the DS (Document Server)"). Auerbach does not explicitly 
discloses using hardware security module to sign manifest, said hardware security 
module being adapted to apply a key associated with a vendor or distributor of said 
software object without revealing said key outside said hardware security module. 

However, Watanabe, in the same field of endeavor of cryptography, discloses 
signing digital document with private key of the signing party without revealing private 
key outside hardware security module (Paragraph 0195, One of the approaches to 
solve the problems of security assurance and enhanced computing speed is the 
use of a hardware security module (HSM) in holding the signature keys (or private 
keys) and executing signature processing.") 

Therefore, it would have been obvious at the time the invention was made to one 
of ordinary skill in the art to use in he system of Auerbach, during a creation of 
cryptographic envelopes, use a hardware security module, as taught by Watanabe to 
provider highly temper resistant and security for the private key of the vendor 
(Watanabe, Paragraph 0195) 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Yogesh Paliwal whose telephone number is (571) 270- 
1807. The examiner can normally be reached on M-F: 7:30 AM - 5:00 PM EST. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kim Vu can be reached on (571) 272-3859. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



YP 

9/11/2007 
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